Database Management Systems:

This chapter outlines the differences between applications and database based systems. It discusses basics regarding database structure and design theory.

Database Management System (DBMS) defined as a collection of programs that enables one to store, modify, and extract information from a database. Originally found only in large companies with the computer hardware needed to support large data sets, DBMSs have more recently emerged as a fairly standard part of any company back office. There are many different types of DBMSs, ranging from small systems that run on personal computers to huge systems that run on mainframes. The following are examples of database applications:

· Computerized library systems
· Automated teller machines
· Flight reservation systems
· Computerized parts inventory systems

From a technical standpoint, DBMSs can differ widely. The terms relational, network, flat, and hierarchical all refer to the way a DBMS organizes information internally. The internal organization can affect how quickly and flexibly you can extract information.
Requests for information from a database are made in the form of a query, which is a stylized question. The set of rules for constructing queries is known as a query language. Different DBMSs support different query languages, although there is a semi-standardized query language called SQL (structured query language). Sophisticated languages for managing database systems are called fourth-generation languages, or 4GLs for short.
The information from a database can be presented in a variety of formats. Most DBMSs include a report writer program that enables you to output data in the form of a report. Many DBMSs also include a graphics component that enables you to output information in the form of graphs and charts.
_

Application based approach to Event Processing (Define Here): The central focus of the application approach is on the processes being performed. The actual data used in the process is not the primary concern but is rather support for the process.
  • Advantages
    • Each application collects and manages its own data, in dedicated, separate, physically distinguishable files for each application.
  • Disadvantages
    • Data Reduncancy (also referred to as data reliability), which increases storage and risk of inconsistency.
    • Data Files are not shareable across applications - Redundant data in different places can pose problems when the data is not updated at the same time or with the same information in all applications.
    • Data is difficult and expensive to obtain
Database Approach (Define here): This approach focuses on the data and how it is stored. In a database approach, the data is not stored in separate files for different applications, but rather in a database where all processes use the same data.
  • Advantages - The data base approach reduces the need for storage of the same data in different applications. In addition, efficiency has increased during the process of business activities.
    • Eliminating data redundancy - Within the application approach, an organization retains the risk of storing and maintaining duplicate information. Using the database approach, we follow the one fact in one place guideline.
    • Ease of maintenance - In the application approach we have to deal with layers of information (as seen on page 148, fig. 5.2). So, if we wanted to change a customer number, we would have to change it at the sales order record layout, the inventory record layout and the customer order layout. In the database approach, the customer number would be stored once. (In database like MS Access, we could easily set the relationships to cascade update; this would allow immediate update of that primary key to all tables.)
    • Reduced storage costs - Yes, data storage is less because there is no longer redundancy in the records, but the DBMS costs significantly more to integrate into the organization; therefore, this advantage is offset.
    • Data integrity - Lack of a unified record under the application approach would cause inconsistencies for both clerical and timing of maintenance reasons.
    • Data independence - The data can be used concurrently and results manipulated by queries, report writing programs, and application processing. In an application approach, the programs would need revisions to provide access to more or less data.
    • Privacy - Database control modules in DBMS are very powerful. Users can be given selective access (read, write, execute privileges). Besides control modules, there is also data classification which sets data objects to a particular level of classification and users are given clearance levels to view the data. Data encryption is also used in this data classification method.
  • Disadvantages - These disadvantages have lead organizations to create a database administrator function within the organization to alleviate these issues.
    • Excessive reliance
      • If the DBMS fails, the entire organization will be unable to process data.
      • Contingency planning must be increased
    • Contention/Concurency - This happens when two users attempt to access the same data at the same time. There are no foolproof solutions, but record locking is a solution (I had the opportunity to use this feature in a program I once created - there was about 2 seconds of downtime in my application every several minutes, but this was to be used by hundreds of people per day, so downtime was not an option. I set the application to set a flag that would prevent other applications from using the data being updated and they would use the backup that was created on the last execution.)
    • Unclear ownership - one department may decide they have the right to edit the same records that another department has a stake in.

There are four types of logical DBMS models:
  1. Hierarchical database model- Records are organized in a pyramid structure. Records at the top contain records below them. This only works well for simple situations because each child record (lower level) can have only one parent record (the record above that includes the lower record).

A hierarchial database model can be visualized as an "upside down tree of data." From this upside down tree, other tables are said to "branch out." All Windows directory management systems act in this manner including Windows Explorer. A hierarchal database model has several advantages including the fact that it reduce redundancy which is why it is often favored over the flat-file model. When a change is made in such a database, the change only has to be processed generally one time which reduces the amount of data needed to be stored on the database, making the database more efficient.

One problem associated with using a hierarchal database is that you cannot add a child table unless it has a parent table to support it. Therefore, if you consider the example of a university database which lists courses and students, and courses is the parent table and students is the child table, then it will not be possible to add a student who has not yet registered for any classes which could prove to be problematic.
basic_tree.gifhierarchaldatapic.gif

Information Retrieved From: "Hierarchial Databases" by Selena Sol
  1. Network database model- This model allows a child record to have more than one parent record. this model could handle more complicated data structures than the hierarchical model.
  2. Relational database model- Data is logically organized in two-dimensional tables. Each individual fact or type of information is store in its own table. A relational DBMS allows users to query table to obtain information from one or more tables. Because of its flexibility, this model is most commonly used. However, the main disadvantage to this model, as originally conceived, is that it only allowed text and numerical information to be stored. It did not allow storage of complex objects such as graphics, audio, or video. Now, object-relational databases allow complex data storage, limiting the need for the fourth type of database model.
  3. Object-oriented database model- Both simple and complex objects can be stored in this model. It includes abstract data types that allows users to define data to be stored, overcoming the limitations of the relational database


As outlined in the attached article, Logical Databases are best suited for: (1) reading the same data for several programs, (2) defining the same user interface for several programs (all applications look the same to the end user), (3) and having a central authorization check (one place that servers as the “gate keeper” to all the organizations data..

Logical Databases
Logical databases are special ABAP programs that retrieve data and make it available to application programs. The most common use of logical databases is still to read data from database tables by linking them to executable ABAP programs.
However, from Release 4.5A, it has also been possible to call logical databases using the function module LDB_PROCESS. This allows you to call several logical databases from any ABAP program, nested in any way. It is also possible to call a logical database more than once in a program, if it has been programmed to allow this. This is particularly useful for programs with type 1.
Logical databases contain Open SQL statements that read data from the database. You do not therefore need to use SQL in your own programs. The logical database reads the program, stores them in the program if necessary, and then passes them line by line to the application program or the function module LDB_PROCESS using an interface work area.

Logical Databases - Views of Data
A logical database provides a particular view of database tables in the R/3 System. It is always worth using logical databases if the structure of the data that you want to read corresponds to a view available through a logical database.
The data structure in a logical database is hierarchical. Many tables in the R/3 System are linked to each other using foreign key relationships. Some of these dependencies form tree-like hierarchical structures. Logical databases read data from database tables that are part of these structures.

The diagram illustrates how the R/3 System might represent the structure of a company. A logical database can read the lines of these tables one after the other into an executable program in a sequence which is normally defined by the hierarchical structure. The term logical database is sometimes used to mean not only the program itself, but also the data that it can procure.

Tasks of Logical Databases
As well as allowing you to read data from the database, logical databases also allow you to program other tasks centrally, making your application programs less complicated. They can be used for the following tasks:
  • Reading the same data for several programs.
The individual programs do not then need to know the exact structure of the relevant database tables (and especially not their foreign key relationships). Instead, they can rely on the logical database to read the database entries in the right order during the GET event.
  • Defining the same user interface for several programs.
Logical databases have a built-in selection screen. Therefore, all of the programs that use the logical database have the same user interface.
  • Central authorization checks
Authorization checks for central and sensitive data can be programmed centrally in the database to prevent them from being bypassed by simple application programs.
  • Improving performance
If you want to improve response times, logical databases permit you to take a number of measures to achieve this (for example, using joins instead of nested SELECT statements). These become immediately effective in all of the application programs concerned and save you from having to modify their source code.








Distinguish between logical and physical database models
Logical Database Model
Physical Database Model
Names all attributes for each entity.
Shows the "How"
Names the primary key for each entity.
Specifies all tables and columns.
Includes all entities and relationships.
Foreign keys are used to identify relationships between tables.
Names the foreign keys.
Physical considerations.
Normalization occurs at this level (to atleast 3rd normal form).
Denormalization may occur .
Doesn't include redundant data.
May include redundant data.
Business experts drive the model.
DBA's drive the model.

For further clarification view this site: http://www.developer.com/tech/article.php/641521


Data Redundancy - a disadvantage of the application approach, problems that can arise because of redundancy include:
  • inconsistencies among the same data in different files when information is updated in one file and not in other files where it also resides
  • increase of storage costs because the system must store and maintain multiple versions of the same data in different files
  • data residing in separate files are not shareable across applications

Relational Database Management System:
A relational database management system (RDBMS) is a database management system (DBMS) that is based on the relational model as introduced by Edgar F. Codd. Relational databases are the most common kind of database in use today (assuming one does not count a file system as a database).

Elements of Relational Databases:
  • Tables- provide a place to store the data
  • Queries- tools that allow users and programmers to access the data stored in various tables, the standard way information is extracted.
  • Forms- on-screen presentations of data in tables and collected by queries from one or more table. Forms are available in printed or electronic format, the latter being the most versatile as it enables the user to type the requested information using a computer keyboard and allows them to easily distribute the content contained within using the Internet and email.
  • Reports- provide printed lists and summaries of data stored in tables or collected by queries from one or more tables

Critisms
Here are criticisms and complaints that can be found with regard to current RDBMS:
  • Vendors don't explore optional query languages outside of SQL. Many feel that SQL needs an update or overhaul, being about 30 years old.
  • They are usually statically-typed. Some feel that dynamically-typed or optional columns may make RDBMS more useful for prototyping or for domains where being nimble in a market is important. (Optional columns are implemented by returning null or blank for columns not defined in a given record.)
  • No scaling - Often one needs a small, lightweight RDBMS for internal (application-specific) processing or experimental applications. After the product becomes more formal, one then wants to upscale to more formal "big iron" RDBMS. However, existing products often do not provide a light-duty version that is compatible with the more formal version. Thus, one often ends up using a different vendor's product for the low-end, but they are not fully compatible with the eventual vendor. A good example of a working light-weight<->big iron product model is SQL Server Express as a light-weight alternative to Microsoft SQL Server. Microsoft appear to have pushed up the SQL Express version to replace their previous desktop data technology, MS Access, which was almost the byword for low-scalability/portability. This point is being addressed.
  • Over-ubiquity - Not all data models require a relational data store, but most developers will pick one up and run with it anyway. As a result, most non-relational DBMS have been starved of development time and innovation.

Data Normalization: Rules for the structure of tables which are based on set theory. Failure to normalize results in anomalies/errors that otherwise might occur when adding, changing, or deleting data stored in the database. Also, an unnormalized table/relation contains repeating groups. To funtion properly, a database should obtain the 3rd normal form; they are inclusive, meaning that each higher normal form includes all lower normal forms. For example, a table in 3NF is in 1NF and in 2NF.
  • 1st Normal Form (1NF): A table that is in 1NF does not contain repeating groups. Additionally, rows are key dependent and uniquely identified by a primary key. However, there are some problems with the first normal form (1NF), such as functional dependencies -- which can lead to problems called update anomalies. For example, an attribute is functionally dependent on a second attribute, if the value for the first attribute determines a single value for the second attribute at any time.
  • 2nd Normal Form (2NF): A table is in 2NF if it is in the first normal form and has no partial dependencies; that is, no non-key attribute is dependent on only a portion of the primary key. It requires that all data elements in a table are functionally dependent on all of the table's primary key.
  • 3rd Normal Form (3NF)- To obtain this form, transitive dependencies must be eliminated (which exists when a non-key field depends on another non-key field which in turn depends on the key - C depends on B which depends on A). For example, page 165: In the SALES_ORDERS table, values in Cust_Name are dependent on Cust_Code, which is a non-key attribute.

Why is data normalization such an important design characteristic of databases? The goal of database normalization is to ensure that every non-key column in every table is directly dependant on the key. The benefits of this goal include: reduced rendundancies, fewer anomalies, and improved efficiencies.